VPC Flow Logs で Peering したVPC間のトラフィックを監視してみる
こんにちは、菊池です。
VPC Peeringで接続したVPCの間で不正な通信が発生していないかを監視可能か、VPC Flow Logsを使って試してみました。
はじめに
VPC Flow Logsは、VPC内のNetwork InterfaceのIPトラフィックをキャプチャする機能で、キャプチャしたデータはCloudWatch Logsに転送・保存されます。
基本的に、不正な通信はSecurity Groupを適切に設定してインスタンスに到達しないようにするのが望ましいです。閉じられたVPC内で発生するトラフィックがSecurity GroupでREJECTされているということは、必要な通信を開放していないか、VPC内のインスタンスが意図しない振る舞いをしていることになります。
今回の目的は、Security GroupでREJECTされたトラフィックを監視することで、意図しないトラフィックが発生していないかを確認することになります。
やってみた
検証構成です。
VPC Peering した2つのVPCで、それぞれVPC Flow Logsを有効にしています。ACCEPT/REJECTの両方を記録しています。
まずは、Security Groupを変更してみてどのようにログが見えるか確認しました。
送信先のInboundでREJECTされた通信
VPC Flow Logsは、ENI単位で、そのENIに付与されたSecurity GroupがACCEPT/REJECTした結果が記録されます。そのため、Outbound通信が許可される送信元のENIでは"ACCEPT"と記録されます。一方で、Inboundで拒否する送信先のENIでは"REJECT"と記録されます。
送信元ENIのログ
送信先ENIのログ
送信元/送信先でログの件数、時間が一致していませんが、VPC Flow Logsがある程度のパケットを1つのログにまとめて記録する際に、揺れがあるためと思われます。こちらについてはもう少し観察して傾向を見てみたいと思います。
送信元のOutboundでREJECTされた通信
送信元のOutboundでリジェクトされた場合、送信元のENIのログにのみ記録されます。送信先のENIには通信が到達しないため、ログが一切残りません。
送信元ENIのログ
このケースでは送信元でREJECTされていました。
メトリクスフィルタの設定
VPC Flow Logsでどのように記録されるかがわかりましたので、不正通信が発生した際に通知をできるよう、メトリクスフィルタを設定します。
フィルタパターンに"172.31." "172.19." "REJECT"を設定します。
この条件により、2つのVPCをまたぐ通信でREJECTされたものが検知可能になります。
記録されました。あとは、通常のCloudWatchアラームと同様に閾値や通知先を設定すればOKです。
さいごに
今回、VPC Flow Logsを詳細に見たのは初めてでした。
キャプチャする対象はENIを通過するものであり、Security Groupに対するACCEPT/REJECTが記録されるということで、その仕様をよく理解した上で監視の条件を設定する必要があるとわかりました。
